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FIELD OF THE INVENTION 



10 The method and apparatus of the present invention relate generally to cryptographic 

systems and, more specifically, to securing cryptographic tokens that must maintain the security of 
secret information in hostile environments. 



15 BACKGROUND OF THE INVENTION 

Most cryptosystems require secure key management. In public-key based security systems, 
private keys must be protected so that attackers cannot use the keys to forge digital signatures, 
modify data, or decrypt sensitive information. Systems employing symmetric cryptography 
similarly require that keys be kept secret. Well-designed cryptographic algorithms and protocols 

20 should prevent attackers who eavesdrop on communications from breaking systems. However, 
cryptographic algorithms and protocols traditionally require that tamper-resistant hardware or 
other implementation-specific measures prevent attackers from accessing or finding the keys. 

If the cryptosystem designer can safely assume that the key management system is 
completely tamper-proof and will not reveal any information relating to the keys except via the 

25 messages and operations defined in the protocol, then previously known cryptographic techniques 
are often sufficient for good security. It is currently extremely difficult, however, to make 
hardware key management systems that provide good security, particularly in low-cost unshielded 
cryptographic devices for use in applications where attackers will have physical control over the 
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device. For example, cryptographic tokens (such as smartcards used in electronic cash and copy 
protection schemes) must protect their keys even in potentially hostile environments. (A token is a 
device that contains or manipulates cryptographic keys that need to be protected from attackers. 
Forms in which tokens may be manufactured include, without limitation, smartcards, specialized 
5 encryption and key management devices, secure telephones, secure picture phones, secure web 
servers, consumer electronics devices using cryptography, secure microprocessors, and other 
tamper-resistant cryptographic systems.) 

A variety of physical techniques for protecting cryptographic devices are known, including 
enclosing key management systems in physically durable enclosures, coating integrated circuits 
10 with special coatings that destroy the chip when removed, and wrapping devices with fine wires 
that detect tampering. However, these approaches are expensive, difficult to use in single-chip 
solutions (such as smartcards), and difficult to evaluate since there is no mathematical basis for 
their security. Physical tamper resistance techniques are also ineffective against some attacks. For 
example, recent work by Cryptography Research has shown that attackers can non-invasively 
1 5 extract secret keys using careful measurement and analysis of many devices' power consumption. 
Analysis of timing measurements or electromagnetic radiation can also be used to find secret keys. 

Some techniques for hindering external monitoring of cryptographic secrets are known, 
such as using power supplies with large capacitors to mask fluctuations in power consumption, 
enclosing devices in well-shielded cases to prevent electromagnetic radiation, message blinding to 
• 20 prevent timing attacks, and buffering of inputs/outputs to prevent signals from leaking out on I/O 
lines. Shielding, introduction of noise, and other such countermeasures are often, however, of 
limited value, since skilled attackers can still find keys by amplifying signals and filtering out noise 
by averaging data collected from many operations. Further, in smartcards and other tamper- 
resistant chips, these countermeasures are often inapplicable or insufficient due to reliance on 
25 external power sources, impracticality of shielding, and other physical constraints. The use of 
blinding and constant-time mathematical algorithms to prevent timing attacks is also known, but 
does not prevent more complex attacks such as power consumption analysis (particularly if the 
system designer cannot perfectly predict what information will be available to an attacker, as is 
often the case before a device has been physically manufactured and characterized). 
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The present invention makes use of previously-known cryptographic primitives and 
operations. For example: U.S. patent 5,136,646 to Haber et al. and the pseudorandom number 
generator used in the RSAREF cryptographic library use repeated application of hash functions; 
anonymous digital cash schemes use blinding techniques; zero knowledge protocols use hash 
5 functions to mask information; and key splitting and threshold schemes store secrets in multiple 
parts. 



SUMMARY OF THE INVENTION 

1 0 The present invention introduces leak-proof and leak-resistant cryptography, mathematical 

approaches to tamper resistance that support many existing cryptographic primitives, are 
inexpensive, can be implemented on existing hardware, and can solve problems involving secrets 
leaking out of cryptographic devices. Rather than assuming that physical devices will provide 
perfect security, leak-proof cryptographic systems are designed to remain secure even if attackers 

15 are able to gather some information about the system and its secrets. One of the essential 

attributes of a leak-proof cryptosystem is that it is "self-healing" such that the value of information 
leaked to an attacker decreases or vanishes with time. This invention describes leak-proof and 
leak-resistant systems that implement symmetric authentication, Diffie-Hellman exponential key 
agreement, ElGamal public key encryption, ElGamal signatures, and the Digital Signature 

20 Standard. 

Leak-proof cryptosystems are able to withstand leaks of up to Zmax bits of information per 
transaction, where Zmax is a security factor chosen by the system designer to exceed to the 
maximum anticipated leak rate. The more general class of leak-resistant cryptosystems 
encompasses those that can withstand leaks, but are not necessarily defined to withstand any 
25 defined maximum information leakage rate. Both the leak-proof and leak-resistant systems of the 
present invention can survive a variety of monitoring and eavesdropping attacks that would break 
traditional (non-leak-resistant) cryptosystems. 

Atypical leak-resistant cryptosystem of the present invention consists of three general 
parts. The initialization or key generation step produces secure keying material appropriate for the 
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scheme. The update process cryptographically modifies the secret key material in a manner 
designed to render useless any information about the secrets that may have previously leaked from 
the system, thus providing security advantages over systems of the background art. The final 
process performs cryptographic operations, such as producing digital signatures or decrypting 
messages, 



BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 shows a leak-proof symmetric authentication method. 
10 Figure 2 shows a leak-resistant Diffie-Hellman exponential key exchange operation, 

y L Figure 3 shows a leak-resistant RSA private key operation. 

5 4 

Figure 4 shows a leak-resistant ElGamal signing operation. 



1 5 DETAILED DESCRIPTION OF THE INVENTION 

Introduction to Symmetric Leak-Proof Cryptography 

The leakage rate L is defined as the number of bits of usefiil information about a 
cryptosystem's secrets that are revealed per operation, where an operation is a cryptographic 
transaction. Although an attacker may be able to collect more than L bits worth of measurement 
20 data, by definition this data yields no more than L bits of useful information about the system's 
secrets. 

The implementer of a leak-resistant system must choose a design parameter L U ax, the 
maximum amount of leakage per operation the system may allow if it is to remain 
uncompromised. Zmax should be chosen conservatively, and normally should significantly exceed 
25 the amount of useful information known to be leaked to attackers about the system's secrets 

during each transaction. Designers do not necessarily need to know accurately or completely the 
quantity and type of information that may leak from their systems; the choice of Zmax may be 
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made using estimates and models for the system's behavior. General factors affecting the choice 
of Lmax include the types of monitoring potentially available to attackers, the amount of error in 
attackers' measurements, and engineering constraints that limit Zmax. (Larger values of L M ax 
increase memory and performance requirements of the device, and in some cases may increase L.) 
5 To estimate the amount of useful information an attacker could collect by monitoring a device's 
power consumption, for example, a designer might consider the amount of noise in the device's 
power usage, the power line capacitance, the useful time resolution for power consumption 
measurements, as well as the strength of the signals being monitored. Similarly, the designer 
knows that timing measurements can rarely yield more than a few bits of information per 
10 operation, since timing information is normally quantized to an integral number of clock cycles. In 
choosing Lmax, the designer must assume that attackers will be able to combine information 
gleaned from multiple types of attacks. If the leakage rate is too large (as in the extreme case 
Q where L equals the key size because the entire key can be extracted during a single transaction), 

Si' additional design features should be added to reduce L and reduce the value needed for Zmax. 

rl 15 Such additional measures can include known methods, such as filtering the device's power inputs, 
t! adding shielding, introducing noise into the timing or power consumption, implementing constant- 

s' time and constant execution path algorithms, and changing the device layout. Again, note that the 

ij designer of a leak-resistant system does not actually need to know what information is being 

?f revealed or how it is leaked; all he or she must do is choose an upper bound for the rate at which 

wff . 20 attackers might learn information about the keys. In contrast, the designer of a traditional system 
faces the much harder task of ensuring that no information about the secrets will leak out. 

There are many ways information about secrets can leak from cryptosystems. For 
example, an attacker can use a high-speed analog-to-digital converter to record a smartcard's 
power consumption during a cryptographic operation. The amount of useful information that can 
25 be gained from such a measurement varies, but it would be fairly typical to gain enough 

information to guess each of 128 key bits correctly with a probability of 0.7. This information can 
reduce the amount of effort required for a brute force attack. For example, a brute force attack 
with one message against a key containing £bits where each bit's value is known with probability 
p can be completed in 
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operations. The reduction in the effort for a brute force attack is equivalent to shortening the key 
by L = log 2 (E(V/ 2 ) / E(*.P)) = !og2(A: - E(*»p) - 1) bits. (For example, in the case of k = 128 and/? 
= 0.7, L is estimated to be about 1 1 bits for the first measurement. With a multiple message 

5 attack, the attacker' s effort can fall to as low as E(£, p) = \.) Attackers can gain additional 

P 

information about the keys by measuring additional operations; unless leak-proofing is used, 
finding the key becomes easy after just a few dozen operations. 

When choosing Lmax, a system designer should consider the signal-to-noise ratio of an 
attacker's measurements. For example, if the signal and noise are of roughly equivalent 

10 magnitude, the designer knows that an attacker's measurements should be incorrect about 25 
percent of the time (e.g., p = 0.75 if only one observation per key bit is possible). Many 
measurement techniques, such as those involving timing, may have signal-to-noise ratios of 1:100 
or worse. With such systems, L is generally quite small, but attackers who can make a large 
number of measurements can use averaging or other statistical techniques to recover the entire 

1 5 key. In extreme cases, attackers may be able to obtain all key bits with virtually perfect accuracy 
from a single transaction (i.e., L = k), necessitating the addition of shielding, noise in the power 
consumption (or elsewhere), and other measures to reduce/? and L. Of course, Luxk should be 
chosen conservatively; in the example above where less than 4 useful bits are obtained per 
operation for the given attack, the designer might select Lmax = 64 for a leak-proof design. 

20 When designing a traditional (i.e., non-leak-resistant) cryptosystem, a careful 

cryptosystem designer must study all possible information available to attackers if he or she is to 
ensure that no analytical techniques could be used to compromise the keys. In practice, many 
insecure systems are developed and deployed because such analysis is incomplete, too difficult 
even to attempt, or because the cryptographers working on the system do not understand or 

25 cannot completely control the physical characteristics of the device they are designing. 

Unexpected manufacturing defects or process changes, alterations made to the product by 
attackers, or modifications made to the product in the field can also introduce problems. Even a 
system designed and analyzed with great care can be broken if new or improved data collection 
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and analysis techniques are found later. In contrast, with leak-resistant cryptography, the system 
designer only needs to define an upper bound on the maximum rate at which attackers can extract 
information about the keys. A detailed understanding of the information available to attackers is 
not required, since leak-proof and leak-resistant cryptosystem designs allow for secret information 
5 in the device to leak out in (virtually) any way, yet remain secure despite this because leaked 
information is only of momentary value. 

In a leak-proof design, with each new cryptographic operation /', the attacker is assumed 
to be able to choose any function F, and determine the Z,MAx-bit result of computing F, on the 
device's secrets, inputs, intermediates, and outputs over the course of the operation. The attacker 
10 is even allowed to choose a new function F, with each new operation. The system is considered 
leak-proof with a security factor n and leak rate Zmax if, after observing a large number of 
operations, an attacker cannot forge signatures, decrypt data, or perform other sensitive 
Q operations without performing an exhaustive search to find an w-bit key or performing a 

tj comparable 0(2") operation. In addition to choosing Luxx, designers also must choose n, and 

f • 1 5 should select a value large enough to make exhaustive search infeasible. 

= Traditional Symmetric Authentication 

H Assume a user wishes to authenticate herself to a server using an w-bit secret key, K, 

b! known to both the server and the user's cryptographic token, but not known to attackers. The 

M ■ 20 cryptographic token must be able to resist tampering to prevent, for example, attackers from 
03 being able to extract secrets from a stolen token. If the user's token has perfect tamper resistance 

(i.e., L=0), authentication protocols of the background art can be used. Typically the server sends 
a unique, unpredictable challenge value R to the user's token, which computes the value A - H(i? 
|| K), where "||" denotes concatenation and H is a one-way cryptographic hash function such as 
25 SHA. The user sends A to the server, which independently computes A (using its copy of K) and 
compares its result with the received value. The user authentication succeeds only if the 
comparison operation indicates a match. 

If the function H is secure and if K is sufficiently large to prevent brute force attacks, 
attackers should not be able to obtain any useful information from the (R, A) values of old 
30 authentication sessions. To ensure that attackers cannot impersonate users by replaying old values 
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of A, the server generates values of R that are (with sufficiently high probability) unique. In most 
cases, the server should also make R unpredictable to ensure that an attacker with temporary 
possession of a token cannot compute future values of .4. For example, R might be a 128-bit 
number produced using a secure random number generator (or pseudorandom number generator) 
5 in the server. The properties of cryptographic hash functions such as H have been the subject of 
considerable discussion in the literature. Hash functions typically provide functionality modeled 
after a random oracle, deterministically producing a particular output from any input. Ideally, such 
functions should be collision-resistant, non-invertable, should not leak partial information about 
the input from the output, and should not leak information about the output unless the entire input 
10 is known. Hash functions can have any output size. For example, MD5 produces 128-bit outputs 
and SHA produces 160-bit outputs. Hash functions may be constructed from other cryptographic 
primitives or other hash functions. 

While the cryptographic security of the protocol using technology of the background art 
may be good, it is not leak-proof; even a one-bit leak function (with L=\) can reveal the key. For 
f? ] 15 example, if the leak function F equals bit (R mod ») of K, an attacker can break the system quickly 
since a new key bit is revealed with every transaction where (R mod n) has a new value. 



rj|: Leak-Proof Symmetric Authentication 

CI The following leak-proof symmetric authentication protocol assumes a maximum leakage 

ilj . 20 rate of £ M ax bits per transaction from the token. The user's token maintains a counter t, which is 
wJ initialized to zero, and an (w+2lMAx)-bit shared secret K t , which is initialized with a secret K 0 . As 

in the traditional protocol, n is the security factor, meaning that attacks of complexity 0(2"), such 
as brute-force of an «-bit key, are acceptable, but there should not be significantly easier attacks. 
(Note that against adversaries performing precomputation attacks based on Hellman's 
25 time/memory trade-off, larger values of n may be in order. Note also that some useful protocol 
security features, such as user and/or server identifiers in the hash operation inputs, have been 
omitted for simplicity in the protocol description. It is also assumed that no leaking will occur 
from the server. For simplicity in the protocol description, some possible security features (such 
as user and/or server identifiers in the hash operation inputs) have been omitted, and it is assumed 
30 that the server is in a physically secure environment. 
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As in the traditional protocol, the server begins the authentication process by generating a 
unique and unpredictable value R at step 105. For example, R might be a 128-bit output from a 
secure random number generator. At step 1 10, the server sends R to the user's token. At step 1 12, 
the token receives R, At step 115, the token increments / by computing t <r- t + 1, At step 120, 
5 the token updates K t by computing K t <- U K (t || K t \ where H K is a cryptographic hash function 
that produces an («+2£max) bit output from the old value of K t and the (newly incremented) value 
of t Note that in the replacement operations (denoted "<^")> th<5 token deletes the old values of t 
and K h replacing them with the new values. By deleting the old K h the token ensures that future 
leak functions cannot reveal information about the old (deleted) value. At step 122, the token uses 

10 the new values off and K t to compute A - H A (K t || 1 1| R\ At step 125, the token sends both t and 
A to the server, which receives them at step 130. At step 135, the server verifies that t is 
acceptable (e.g., not too large but larger than the value received in the last successful 
authentication). If t is invalid, the server proceeds to step 175. Otherwise, at step 140, the server 
initializes / to zero and K t ' to Ko. At step 145, the server compares i with the received value of r, 

15 proceeding to step 160 if they are equal. Otherwise, at step 150, the server increments i by 

computing / <- / + 1. At step 155, the server computes K t ' <~~ H K (i || K t % then proceeds back to 
step 145. At step 160, the server computes A ' - H A (K,' || 1 1| R)> Finally, at step 165, the server 
compares A and A \ where the authentication succeeds at step 170 if they match, or fails at 175 if 
they do not match. 

20 If, at any time, any 2Lmax (or fewer) bits of useful information about the secret are known 

to the attacker, there are still (n+2Lujud~ZLuAK = «or more unknown bits. These n bits of 
unknown information ensure that attacks will require 0(2") effort, corresponding to the desired 
security factor. 

This leak-proof design assumes that at the beginning of any transaction the attacker may 
25 have Imax bits of useful information about the state of the token (e.g., K t ) that were obtained 
using the leak function F in previous operation. During the transaction, the attacker can gain an 
additional Lmax bits of useful information from the token. However, the attacker should have no 
more than Zmax bits of useful information about K t at the end of the transaction. The property that 
attackers lose useful information during normal operation of the system is a characteristic of the 
30 leak-proof cryptosystem. In general, this information loss is achieved when the cryptosystem 
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performs operations that convert attackers' useful partial information about the secret into useless 
information. (Information is considered useless if it gives an attacker nothing better than the 
ability to test candidate values in an 0(2") exhaustive search or other "hard" operation. For 
example, if exhaustive search of Xis hard and H is a good hash function, H(Z) is useless 
5 information to an attacker trying to find X) 

Thus, the attacker is assumed to begin with Lmax bits of useful information about K t 
before the token's K t H K <7 || K t ) computation. (Initial information about anything other than K t 
is of no value to an attacker because K t is the only secret value in the token. The algorithm H K and 
the value of t are not assumed to be secret.) The attacker's information can be any function of K t 
10 produced from the previous operation's leaks, 

During the course of a transaction, the leak function F might reveal up to Lmax 
information about the system and its secrets. Any information contained in the system may be 
G leaked by F with only two restrictions; it should not reveal useful new information about values of 

s| K t that were deleted before the operation started, and F should not reveal useful information about 

i7l 1 5 values of K t that will be computed in future operations. These assumptions are completely 
4* reasonable, since real-world leaks would not reveal information about deleted or not-yet-existent 

J' data. The only way information about future K t values could be leaked would be the bizarre case 

where the leak function itself included, or was somehow derived from, the function H K . In 
£! practice, these assumptions about F are academic and of little concern. However, they are 

Cl * 20 relevant when constructing proofs to demonstrate the security of a leak-proof system. For 
%v - example, a hypothetical cry ptosy stem could theoretically leak information about H K (* + 3 || H K (* + 

2 || H K (* + 1 || H K (* || K t )))) during the first operation, about H K (f + 2 || H K (* + 1 || H K (* || Kt))) in 
the next, about H K (* + 1 || H K (* || K t )) in the third, and about H K (* || K t ) in the fourth. Because t 
and K t are updated during each operation, these expressions are all equal to H K (^ || K t ) from the 
25 fourth operation, causing four leaks about a single value of K t and providing 4L bits of useful 
information about K t after the end of the fourth operation. 

If the leak occurs at the beginning of the H K computation, it could give the attacker up to 
2L M ax bits of useful information about the input value of K t > Because K t contains (2LuAx+n) bits 
of secret information and the attacker may have up to 2Lmax bits of useful information about the 
30 initial value of K h there remain at least (2Zmax+^)-2Z,max = n bits of information in K t that are 
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secret. The hash function H K effectively mixes up these n bits to produce a secure new K, during 
each transaction such that the attacker's information about the old K t is no longer useful. 

If the leak occurs at the end of the H K computation, it could give an attacker up to Z-max 
bits of information about the final value of H K , yielding Lmax bits of information about the input to 
5 the subsequent transaction. This is not a problem, since the design assumes that attackers have up 
to Luax bits of information about K t at the beginning of each transaction. 

A third possibility is that the attacker's Luax bits of information might describe 
intermediates computed during the operation H K . However, even if the attacker could obtain Xmax 
new bits of information about the input to H K and also L M ax bits of information about the output 
10 from H K , the system would be secure, since the attacker would never have more than 2Lmax bits 
of information about the input K t or more than Imax bits of information about the output K t . 
Provided that Luax bits of information from within H K cannot reveal more than Luax bits of 
information about the input, or more than Luax bits of information about the output, the system 
will be secure. This will be true unless H K somehow compresses the input to form a short 
1 5 intermediate which is expanded to form the output. While hash functions whose internal states are 
smaller than their outputs should not be used, most cryptographic hash functions are fine. 

A fourth possibility is that part or all of the leak could occur during the ,4 = U A (K t \\ 1 1| R) 
calculation. The attacker's total "budget" for observations is £max bits. If i x bits of leak occur 
during the H K computation, an additional la bits of information can leak during the A = H A (K t || t 
20 || R) operation, where L 2 < Luax -L^Jf the second leak provides information about K t , this is no 
different from leaking information about the result of the H K computation; the attacker will still 
conclude the transaction with no more than Luax bits of information about K t because U + U * 
Luax- However, the second leak could reveal information about A. I£A must be kept secure 
against leaks (to prevent, for example, an attacker from using a leak to capture A and using A 
25 before the legitimate user can), the size of A should include an extra Luax bits (to provide security 
even if L 2 =Luax). Like H K , H A should not leak information about deleted or future values ofK, 
that are not used in or produced by the given operation. As with the similar assumptions on leaks 
from H K , this limitation is primarily academic and of little practical concern, since real-world leak 
functions do not reveal information about deleted or not-yet-computed data. However, designers 
30 might be cautious when using unusual designs for H A that are based on or derived from H K , 
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particularly if the operation U A (K t || t \\ R) could reveal useful information about the result of 
computing H K (t \\ K t ). 

Other Leak-Proof and Leak-Resistant Symmetric Schemes 

5 Leak-proof symmetric data verification is often useful if, for example, a device needs to 

support symmetrically-signed code, data, or parameter updates. In existing systems, a hash or 
MAC of the data is typically computed using a secret key and the data is rejected if computed 
hash or MAC does not match a value received with the data. For example, a MAC may be 
computed as HMAC(X, data), where HMAC is defined in "RFC 2104, HMAC: Keyed-Hashing 
10 for Message Authentication" by H. Krawczyk, M. Bellare, and R. Canetti, 1997. Traditional (non- 
leak-resistant) designs are often vulnerable to attacks including power consumption analysis of 
^ MAC functions and timing analysis of comparison operations. 

O In a leak-proof verification protocol, the verifying device maintains a counter t and a key 

s| K t , which are initialized (for example at the factory) with t <- 0 and K t <- K 0 . Before the 

tt 15 transaction, the token provides t to the device providing the signed data ("signer"). The signer 
% uses t to compute K t+ i ' from K 0 using the relation K, = H K (/' || i^-i), computes signature S' = 

r HMAC(X, +/ ', data), and sends (data, S\ f) to the verifying device. The verifier confirms that the 

yj received value of t matches its value of t, and rejects the signature if it does not. If / matches, the 

Ef token increments t and updates K t in its nonvolatile memory by computing t <- t + 1 and K, <r- 

tf> • 20 H K (* || K t ). (Note that in some applications, if the received value of t is larger than the internal 
M value but the difference is not unreasonably large, it may be more appropriate to accept the 

signature and perform multiple updates to K, instead of rejecting the signature outright.) Finally, 
the verifier computes S = HMAC(X r , data) and verifies that S = S\ rejecting the signature if S ' 
does not equal the vaiue of S received with the data. 
25 Leak-resistant symmetric cryptography can be tailored to a wide variety of applications 

and environments. If data encryption is desired instead of authentication, the key if, may be used 
for encryption. If communications between the device and the server are unreliable (for example if 
the server uses voice recognition or manual input to receive t and A), then small errors in the 
signature may be ignored. (One skilled in the art will appreciate that many functions may be used 
30 to determine whether a signature corresponds to its expected value.) The order of operations and 
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of data values may be adjusted, or additional steps and parameters may be added, without 
significantly changing the invention. To save on communication bandwidth or memory, the high 
order bits or digits of t may not need to be communicated or remembered. As a performance 
optimization, devices need not recompute K t from K 0 with each new transaction. For example, 
5 when a transaction succeeds, the server can discard K 0 and maintain the validated version of K t . If 
bi-directional authentication is required, the protocol can include a step whereby the server can 
authenticates itself to the user (or user's token) after the user's authentication is complete, If the 
server needs to be secured against leaks as well (as in the case where the role of "server" is played 
by an ordinary user), it can maintain its own counter t. In each transaction, the parties agree to use 

10 the larger of their two t values, where the device with the smaller t value performs extra updates 
to K t to synchronize t. In an alternate embodiment for devices that contain a clock and a reliable 
power source (e.g., battery), the update operation may be performed periodically, for example by 
computing K t <~ H K (f il K t ) once per second. The token uses the current K t to compute A = U A (K t 
|| t 1| R) or, if the token does not have any means for receiving R 9 it can output A = U A (K t ). The 

15 server can use its clock and local copy of the secret to maintain its own version ofK t , which it can 
use to determine whether received values of A are recent and correct. The forgoing shows that the 
method and apparatus of the present invention can be implemented using numerous variations and 
modifications to the exemplary embodiments described herein, as would be known by one skilled 
in the art, 

20 

Traditional Certified Diffie-Hellman 

While symmetric cryptosystems are sufficient for some applications, asymmetric 
cryptography is required for many applications. There are several ways leak resistance can be 
incorporated into public key cryptosystems, but in the ideal case it should have as little impact as 
25 possible on the overall system architecture. Most of the exemplary designs have thus been chosen 
to incorporate leak resistance into widely used cryptosystems in a way that only alters the key 
management device, and does not affect the certification process, certificate format, public key 
format, or algorithms for using the public key, 

Typical protocols in the background art for performing certified Diffie-Hellman 
30 exponential key agreement involve two communicating users (or devices) and a certifying 
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authority (CA). The CA uses an asymmetric signature algorithm (such as DS A) to sign certificates 
that specify a user's public Diffie-Hellman parameters (the prime p and generator g\ public key 
(p* mod g, where x is the user's secret exponent), and auxiliary information (such as the user's 
identity, a description of privileges granted to the certificate holder, a serial number, expiration 
5 date, etc.). Certificates may be verified by anyone with the CA's public signature verification key. 
To obtain a certificate, user U typically generates a secret exponent (x u \ computes his or her own 
public key y u = g* u mod p , presents^ along with any required auxiliary identifying or 
authenticating information (e.g., a passport) to the CA, who issues the user a certificate C Ut 
Depending on the system, p and g may be unique for each user, or they may be system-wide 
10 constants (as will be assumed in the following description of Diffie-Hellman using the background 
art). 

Using techniques of the background art, Alice and Bob can use their certificates to 
establish a secure communication channel. They first exchange certificates (Cmi™ and Csob)^ Each 
verifies that the other's certificate is acceptable (e.g., properly formatted, properly signed by a 
S 15 trusted CA, not expired, not revoked, etc.). Because this protocol will assume that/? and g are 
constants, they also check that the certificate's p and g match the expected values. Alice extracts 
Bob's public key (ynob) from C Bo b and uses her secret exponent (x M i<*) to compute 
^Aiice = (>Bob) XAlicc mod P- Bob uses Ws secret exponent and Alice's public key to compute 
z Bob = (y Mice )*** mod P- If everything works correctly, 2ahm = z B o\» since: 
^ce=(vBob)^ c ^odp 

20 =fe***)**tnodp 

^AUoo)** mod/? 



= z 



Bob ' 



Thus, Alice and Bob have a shared key z = ^Aiice = £ Bo b. An attacker who pretends to be 
Alice but does not know her secret exponent (xtahco) will not be able to compute 
^Mice = 0 } Boh) XMiw mod P correctly. Alice and Bob can positively identify themselves by showing 
25 that they correctly found z. For example, each can compute and send the other the hash of z 
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concatenated with their own certificate. Once Alice and Bob have verified each other, they can 
use a symmetric key derived from z to secure their communications. (For an example of a 
protocol in the background art that uses authenticated Diffie-Hellman, see "The SSL Protocol 
Version 3,0" by A, Freier, P. Karlton, and P. Kocher, March 1996,) 

Leak-Resistant Certified Diffie-Hellman 

A satisfactory leak-resistant public key cryptographic scheme must overcome the problem 
that, while certification requires the public key be constant, information about the corresponding 
private key should not leak out of the token that contains it. In the leak-proof symmetric protocol 
described above, the design assumes that the leak function reveals no useful information about old 
deleted values of K t or about future values of K t that have not yet been computed. Existing public 
key schemes, however, require that implementations repeatedly perform a consistent, usually 
deterministic, operation using the private key. For example, in the case of Diffie-Hellman, a leak- 
resistant token that is compatible with existing protocols and implementations must be able to 
perform the secret key operation,/ mod /?, while ensuring that the exponent x remains secret. The 
radical reshuffling of the secret provided by the hash function H K in the symmetric approach 
cannot be used because the device must be able to perform the same operation consistently, 

The operations used by the token to perform the private key operation are modified to add 
leak resistance using the following variables: 

Comment — 

First part of the secret key (in nonvolatile updateable memory) 
Second part of the secret key (in nonvolatile updateable memory) 
The generator (not secret). 

The public prime, preferably a strong prime (not secret). 

The prime p and generator g may be global parameters, or may be specific to individual users or 
groups of users (or tokens). In either case, the certificate recipient must be able to obtain/? and g 
securely, usually as built-in constants or by extracting them from the certificate. 

To generate a new secret key, the key generation device (often but not always the 
cryptographic token that will contain the key) must first obtain or generate/? and g 9 where/? is the 
prime and g is a generator mod />. If/? and g are not system-wide parameters, algorithms known 
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in the background art for selecting large prime numbers and generators may be used. It is 
recommended that p be chosen with ^-also prime, or at least that (ftp) not be smooth. (When-^ 1 - 
is not prime, information about Xi and x 2 modulo small factors of ^ (p) may be leaked, which is 
why it is preferable that <j> (p) not be smooth. Note that <j> denotes Euler's totient function.) Once 
5 p and g have been chosen, the device generates two random exponents xi and x 2 . The lowest- 
order bit of xi and of x 2 is not considered secret, and may be set to 1. Using p, g, x x , and x 2 , the 
device can then compute its public key as g*'* 2 mod p and submit it, along with any required 
identifying information or parameters needed (e.g., p and g), to the CA for certification. 

Figure 2 illustrates the process followed by the token to perform private key operations. 

10 At step 205, the token obtains the input message^, its own (non-secret) prime/?, and its own 
secret key halves (xi and x 2 ). J£x h x 2 , and p are stored in encrypted and/or authenticated form, 
they would be decrypted or verified at this point. At this step, the token should verify that \<y< 
p-l. At step 210, the token uses a random number generator (or pseudorandom number 
generator) to select a random integer b 0y where 0 < bo <p. At step 215, the token computes 

15 b x = £ 0 -1 m °d P- The inverse computation mod p may be performed using the extended Euclidian 
algorithm or the formula b x = b/ {p) ~ l mod p. At step 220, the token computes b 2 = b* mod p. At 
this point, fa is no longer needed; its storage space may be used to store b 2 . Efficient algorithms 
for computing modular exponentiation, widely known in the art, may be used to complete step 
220. Alternatively, when a fast modular exponentiator is available, the computation b 2 may be 

20 performed using the relationship b 2 = b 0 * { " yXl mod p. At step 225, the token computes 

b 3 = bf mod p. At this point, b 2 is no longer needed; its storage space may be used to store fa. 
At step 230, the token computes z 0 = fay mod p. At this point, y and b 0 are no longer needed; 
their space may be used to store r x (computed at step 235) and z 0 . At step 235, the token uses a 
random number generator to select a random integer r h where 0 < n < <f)(p) and gcd(ri, ftp)) = 1. 

25 (If £± is known to be prime, it is sufficient to verify that n is odd.) At step 240, the token 

updates x t by computing xi <- Xi n mod (ftp). The old value of Xi is deleted and replaced with the 
updated value. At step 245, the token computes r 2 = (n 1 ) mod (fcp). If is P^e, then r 2 can 
be found using a modular exponentiator and the Chinese Remainder Theorem. Note that n is not 
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needed after this step, so its space may be used to store r 2 . At step 250, the token updates x 2 by 
computing x 2 <- x 2 r 2 mod #p). The old value of x 2 should be deleted and replaced with the 
updated value. At step 255, the token computes z, = (z 0 f mod p. Note that z 0 is not needed after 
this step, so its space may be used to store z h At step 260, the token computes z 2 = (z,)* 2 mod p. 
5 Note that zi is not needed after this step, so its space may be used to store z 2 . At step 265, the 
token finds the exponential key exchange result by computing z - z 2 b 3 mod p. Finally, at step 
270, the token erases and frees any remaining temporary variables. 

The process shown in Figure 2 correctly computes z-f modi?, where x = x\x 2 mod (ftp), 

since: 

z = z 2 b 3 mod p 
= (z* 1 mod mod p) mod P 

= ((z 0 * mod /^jfV' mod^)mod/> 
= (b 0 y mod pY x * (v* mod pf* 1 mod p 

= y x mod /?. 

The invention is useful for private key owners communicating with other users (or 
devices) who have certificates, and also when communicating with users who do not. For users or 
devices lacking certificates or public keys that must be constant, secure long-term secret storage 
is usually not required since uncertified Diffie-Hellman may be used. 

1 5 if Alice has a certificate and wishes to communicate with Bob who does not have a 

certificate, the protocol proceeds as follows. Alice sends her certificate (Cako) to Bob, who 
receives it and verifies that it is acceptable. Bob extracts >>Aii 0 e (along with/?Aii ce and g M ic e , unless 
they are system-wide parameters) from Cai**. Next, Bob generates a random exponent x B a, where 
0 < xab < ^(Paiioo). Bob then uses his exponent x m and Alice's parameters to calculate 

20 y BA = feA,,,.^ )mod p Mice and the session key z = (y Alice * BA )mod p Mee . Bob sends ysA to Alice, 
who performs the operation illustrated in Figure 2 to update her internal parameters and derive z 
from.VBA. Alice then proves that she computed z correctly, for example by sending Bob H(z || 
CAiice). (Alice cannot authenticate Bob because he does not have a certificate. Consequently, she 
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does not necessarily need to verify that he computed z successfully.) Finally, Alice and Bob can 
use z (or, more commonly, a key derived from z) to secure their communications. 

If both Alice and Bob have certificates, the protocol works as follows. First, Alice and 
Bob exchange certificates (Cm\c S and C Bo b), and each verifies that other's certificate is valid. Alice 
5 then extracts the parameters /?Bob, gBob, and y Bo b from C B ob, and Bob extracts p M i^, gm<*, and 
from CAiiee. Alice then generates a random exponent jcab where 0 < xab < <ftp&<>*), computes 
J^ab = (g^)"" mod Pbob > and computes z m - Ow) 6 " mod^ Bob . Bob generates a random x BA 
where 0 <x BA < <}>(pm<*), computes y nA = (g Mice Y BA modp Mice , and computes 
z BA - (y^y™ m °d Pm™ • Bob sends >^ A to Alice, and Alice sends ym to Bob. Alice and Bob 
10 each perform the operation shown in Figure 2, where each uses the prime/? from their own 

certificate and their own secret exponent halves (x x and x 2 ). For the message^ in Figure 2, Alice 
|| uses >fe A (received from Bob), and Bob uses y^ (received from Alice). Using the process shown 

H in Figure 2, Alice computes z. Using z and zab (computed previously), she can find a session key 

C K, This may be done, for example, by using a hash function H to compute K = H(z || zab). The 

A 1 5 value of z Bob obtains using the process shown in Figure 2 should equal Alice's z m , and Bob's 
P z B a (computed previously) should equal Alice's z. If there were no errors or attacks, Bob should 

[3 thus be able to find K 9 e.g., by computing K - H(z BA II z). Alice and Bob now share K. Alice can 

CI prove her identity by showing that she computed K correctly, for example by sending Bob U(K || 

I|{ • CMice). Bob can prove his identity by sending Alice H(K || C Bo b)> Alice and Bob can then secure 

^ 20 their communications by encrypting and authenticating using K or a key derived from K. 

Note that this protocol, like the others, is provided as an example only; many variations 
and enhancements of the present invention are possible and will be evident to one skilled in the 
art. For example, certificates may come from a directory, more than two parties can participate in 
the key agreement, key escrow functionality may be added, the prime modulus/? may be replaced 
25 with a composite number, etc. Note also that Alice and Bob as they are called in the protocol are 
not necessarily people; they would normally be computers, cryptographic devices, etc. 

For leak resistance to be effective, attackers must not be able to gain new useful 
information about the secret variables with each additional operation unless a comparable amount 
of old useful information is made useless. While the symmetric design is based on the assumption 
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that leaked information will not survive the hash operation H K , this design uses multiplication 
operations mod <Kp) to update xi and x 2 . The most common variety of leaked information, 
statistical information about exponent bits, is not of use to attackers in this design, as the 
exponent update process (x x <~ xi n mod tp(p) and x 2 <- x 2 r 2 mod ftp)) destroys the utility of this 
5 information. The only relevant characteristic that survives the update process is that xix 2 mod <f>(p) 
remains constant, so the system designer must be careful to ensure that the leak function does not 
reveal information allowing the attacker to find new useful information about xix 2 mod (ftp). 

There is a modest performance penalty, approximately a factor of four, for the leak- 
resistant design as described. One way to improve performance is to remove the blinding and 
10 unblinding operations, which are often unnecessary. (The blinding operations prevent attackers 
from correlating input values of y with the numbers processed by the modular exponentiation 
ftl operation.) Alternatively or additionally, it is possible to update and reuse values of fa, fa, n, and 

5 r 2 by computing fa <- (faf mod p, fa <- (faf mod p, n «- (>i) w mod #p), and r 2 <- (r 2 ) w mod 

~! where v and w are fairly short random exponents. Note that the relationship 

15 b 3 <r- b~ XlXl modp remains true when fa and fa are both raised to the power v (modp). The 
I? relationship r 2 = (rf 1 ) mod <fip) also remains true when n and r 2 are exponentiated (mod (ftp)). 

b Other parameter update operations may also be used, such as exponentiation with fixed exponents 

rf * (e.g., v = w = 3), or multiplication with random values and their inverses, mod p and <j<p). The 

r | time per transaction with this update process is about half that of the unoptimized leak-resistant 

il 20 implementation, but additional storage is required and care must be taken to ensure that b 0> fa, r u 
and r 2 will not be leaked or otherwise compromised. 

It should also be noted that with this particular type of certified Diffie-Hellman, the 
negotiated key is the same every time any given pair of users communicate. Consequently, though 
the blinding operation performed using b 0 and fa does serve to protect the exponents, no 
25 algorithm can ensure that the result K will not be leaked in the final step or by the system after the 
process is complete. If storage is available, parties could keep track of the values of^ they have 
received (or their hashes) and reject duplicates/Alternatively, to ensure that a different result is 
obtained from each negotiation, Alice and Bob can generate and exchange additional exponents, 
WAlioB and w B ob, for example with 0 < w < 2™ (where 2 128 «p). Alice sets y = iy BA f MM mod/? 

-19- 

leakResistProvisional 



instead of just y - y** and Bob sets y = (y mod p instead of y = Vab before performing 

the operation shown in Figure 2. 

Leak-Resistant RSA 

To give RSA private key operations resistance to leaks, it is possible to divide the 
exponent into two halves such that information about either half is destroyed with each operation. 
Private key signing operations with the RSA algorithm involve computing S = M* mod n, where 
Mis the message, S is the signature (verifiable usingM= S° mod n), d = e l mod tfn), and n =pq, 
where n and e are public and p and q are secret primes. For RSA to be secure, d, p, and q 
must all be secret. Private key RSA decryption operations are virtually identical to signing, since 
the decrypted message Mis recovered from the ciphertext C by computing M = C* mod n. 
Although the following discussion uses variable names from the RSA signing operation, the same 
techniques may be applied identically to decryption. 

A leak-resistant scheme for RSA implementations may be constructed as illustrated in 
Figure 3. At step 300, prior to the commencement of any signing or decryption operations, the 
device is initialized with (or creates) the public and private keys. The device contains the public 
modulus n and the secret key components d h d 2 , and z, and k, where k is a prime number of 
medium-size (e.g., 0 < k < 2 128 ) chosen at random, z = kfin), d x is a random number such that 0 
di<z and gctfdu z) = 1, and d 2 = (e' 1 mod #n))(«/f 1 mod z) mod z. Techniques for generating 
the initial RSA primes (e.g., p and q) and modulus (») are well known in the background art. At 
step 305, the device computes a random prime k' of medium size (e.g., 0 < k' < 2 128 ). (Algorithms 
for efficiently generating prime numbers are known in the art.) 

At step 303, the device (token) receives a message M to sign (or to decrypt). At step 310, 
the device updates z by computing z<-k'z. At step 315, the device updates z again by computing 
z*-zlk (There should be no remainder from this operation, since k divides z.) At step 320, k is 
replaced with k'by performing k <- Because k' will not be used in subsequent operations, its 
storage space may be used to hold R (produced at step 325). At step 325, the device selects a 
random R where 0 < R < z and gcd(i?, r) = 1 . At step 330, the device updates d, by computing d x 
<- diR mod z. At step 335, the device finds the inverse of R by computing R' <- R~ l mod z using, 
for example, the extended Euclidian algorithm. Note that R is no longer needed after this step, so 
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its storage space may be erased and used to hold R '. At step 340, the device updates d 2 by 
computing d 2 <- d 2 R ' mod z. At step 345, the device computes S 0 =M d ' mod n , where M is the 
input message to be signed (or the message to be decrypted). Note that Mis no longer needed 
after this step, so its storage space may be used for S 0 . At step 350, the device computes 
5 S = S 0 " x modn , yielding the final signature (or plaintext if decrypting a message). Leak-resistant 
RS A has similar security characteristics as normal RS A; standard message padding, post- 
processing, and key sizes may be used. Public key operations are also performed normally (e.g., 
M= S° mod «). 

A simpler RS A leak resistance scheme may be implemented by splitting the exponent d 
10 into two halves dx and d 2 such that dx + d 2 = d. This can be achieved during key generation by 
choosing di to be a random integer where 0 < dx <, d, and choosing d 2 <-d-di. To perform 
5V private key operations, the device needs dx and d 2 , but it does not need to contain d. Prior to each 

O private key operation, the cryptographic device identifies which of di and d 2 is larger. If di > d 2 , 

q then the device computes a random integer r where 0<,r<,d u adds r to d 2 (i.e., d 2 <-d 2 + r), and 

% 15 subtracts r from d x (i.e., d x <- di - r). Otherwise, if d x <s d 2 , then the device chooses a random 
■£ integer r where 0 <L r <, d 2 , adds r to d x (i.e., dx <- di + r), and subtracts r from d 2 (i.e., d 2 <-d 2 - 

□ r). Then, to perform the private key operation on a message M> the device computes 

r? = M dl mod w, s,=M dl mod w, and computes the signature S = s^ 2 mod ». While this approach 

JJ . of splitting the exponent into two halves whose sum equals the exponent can also be used with 

^ 20 Diffie-Hellman and other cryptosystems, dividing the exponent into the product of two numbers 
mod ^(p) is usually preferable since the assumption that information about di+d 2 will not leak is 
less conservative than the assumption that information about x x x 2 mod <fo>) will not leak. In the 
case of RSA, updates mod (ftn) cannot be done safely, since (ftp) must be kept secret. 

When the Chinese Remainder Theorem is required for performance, it is possible to use 
25 similar techniques to add leak resistance by maintaining multiples of the secret primes (p and q) 
that are updated every time (e.g., multiplying by the new multiple then dividing by the old 
multiple). These techniques also protect the exponents (d p and dq) as multiples of their normal 
values. At the end of the operation, the result S is corrected to compensate for the adjustments to 
d p , d q ,p, and q. In some cases, other techniques may also be appropriate. For example, exponent 
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vector codings may be rechosen frequently using, for example, a random number generator. Also, 
Montgomery arithmetic may be performed mod j where j is a value that is changed with each 
operation (as opposed to traditional Montgomery implementations wherey is constant withy = 
2*). The forgoing shows that the method and apparatus of the present invention can be 
5 implemented using numerous variations and modifications to the exemplary embodiments 
described herein, as would be known by one skilled in the art. 

Leak-Resistant EIGamal Public Key Encryption and Digital Signatures 

The private key in the EIGamal public key encryption scheme is a randomly selected secret 

10 a where 1 < a < p-2. The non-secret parameters are a prime p, a generator a, and ot mod p. To 
encrypt a message m, one selects a random k (where 1 < k < p~2) and computes the ciphertext (y, 
S) where y= of mod p and <5= m(a a mod pf mod p. Decryption is performed by computing m = 
S(f~ l ~ a ) mod p. (See the Handbook of Applied Cryptography by A. Menezes, P. van Oorschot, 
and S. Vanstone, 1997, pages 294-298, for a description of EIGamal public-key encryption), 

15 To make the EIGamal public-key decryption algorithm leak-resistant, the secret exponent 

(p _ i _ a) is stored in two halves a x and a 2 , such that a x a 2 = (ftp)~a) mod ftp). When generating 
EIGamal parameters for this leak-resistant implementation, it is recommended, but not required, 
thatp be chosen with prime so that ftp)l2 is prime. The variables a x and a 2 are normally 
chosen initially as random integers between 0 and ftp). Alternatively, it is possible to generate a 

20 first, then choose a x and a 2> as by selecting a x relatively prime to ftp) and computing a 2 = {a~ x 
mod ftp))(af l mod ftp)) mod ftp). 

Figure 4 illustrates the leak-resistant EIGamal decryption process. At step 405, the 
decryption device receives an encrypted message pair (y 9 8). At step 410, the device selects a 
random r\ where 1 < ri < ftp) and gcd(n, ftp)) = 1. At step 415, the device updates a x by 

25 computing a x <- can mod ftp), over-writing the old value of a x with the new value. At step 420, 
the device computes the inverse of n by computing r 2 = (ri)" 1 mod ftp). Because n is not used 
after this step, its storage space may be used to hold r 2 . Note that if is prime, then r 2 may also 
be found by finding r 2 ' = r^ 1 * 2 " 2 mod^ 1 , and using the CRT to find r 2 (mod/? - 1). At step 425, 
the device updates a 2 by computing a 2 <r~ a 2 r 2 mod ftp). At step 430, the device begins the 
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private key (decryption) process by computing y* x mod p . At step 435, the device computes 

m - Sim')" 2 mod p and returns the message m, If verification is successful, the result equals the 

original message because: 

{S)im^ mod p = {n(a a j)^ ai mod pf % mod p 
= {^a^^ im ^ ip) )mod p 

= \ma«%a k mod p^^Jtnod /> 

^(ma^Xa^modp 

= m 

As with the ElGamal public key encryption scheme, the private key for the ElGamal digital 
signature scheme is a randomly-selected secret a, where 1 < a < p~2. The public key is also 
similar, consisting of a prime p, a generator a, and public parameter y where y = ct mod p. To 
sign a message m, the private key holder chooses or precomputes a random secret integer k 
(where 1 < k < p-2 and k is relatively prime to p-l) and its inverse, k~ l mod $p). Next, the signer 
computes the signature (r, s), where r = of mod p, s~ i[k" 1 mod^(p))[H(w) -ar])mod^0?), and 
H(w) is the hash of the message. Signature verification is performed using the public key (p, a, y) 
by verifying that 1 < r <p and by verifying that// mod p = o^" 0 mod 

To make the ElGamal digital signing algorithm leak-resistant, the token containing the 
private key maintains three persistent variables, a k , w y and r. Initially, a k = a (the private 
exponent), w-l, and r = <x When a message /w is to be signed (or during the precomputation 
before signing), the token generates a random number b and its inverse b~ x mod $p), where b is 
relatively prime to (ftp) and 0 < b < $/?), The token then updates a k , w, and r by computing a k <- 
(a^Xr 1 ) mod ^), w ^ (wX*" 1 ) mod #p), and r «- (/) mod p. The signature (r, 5) is formed 
from the updated value of r and s, where s = (m>(h(w)- ^r))mod^(p). Note that a*, and r are 
not randomized prior to the first operation, but should be randomized before exposure to possible 
attack, since otherwise the first operation may leak more information than subsequent ones. It is 
thus recommended that a dummy signature or parameter update with a k <- (a k )(b~ x ) mod $p), w 
<~ (w)(b~ l ) mod $p) 9 and r <™ (r b ) mod p be performed immediately after key generation. Valid 
signatures produced using the tamper-resistant ElGamal algorithm may be checked using the 
normal ElGamal signature verification algorithm. 
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It is also possible to split all or some the ElGamal variables into two halves as part of the 
leak resistance scheme. In such a variant, a is replaced with a\ and a 2 , w with wi and W2, and r 
with r x and r 2 . It is also possible to reorder the operations by performing, for example, the 
parameter updates as a precomputation step prior to receipt of the enciphered message. Other 
variations and modifications to the exemplary embodiments described herein will be evident to 
one skilled in the art. 

Leak-Resistant DSA 

The Digital Signature Algorithm (DSA, also known as the Digital Signature Standard, or 
DSS) is defined in "Digital Signature Standard (DSS)," Federal Information Processing Standards 
Publication 186, National Institute of Standards and Technology, May 19, 1994 and described in 
detail in the Handbook of Applied Cryptography , pages 452 to 454, In non-leak-proof systems, 
the private key consists of a secret parameter a, and the public key consists of (p, q, a, y\ where 
p is a large (usually 512 to 1024 bit) prime, q is a 160-bit prime, a is a generator of the cyclic 
group of order q mod /?, and>> - ot mod p. To sign a message whose hash is H(w), the signer first 
generates (or precomputes) a random integer k and its inverse k~ l mod q, where 0<k<q. The 
signer then computes the signature (r > s), where r = (cf mod p) mod q, and s = (AT 1 mod q)(H(m) 
4- af) mod q. 

To make the DSA signing algorithm leak-resistant, the token containing the private key 
maintains two variables in nonvolatile memory, a* and k, which are initialized with ctk^a and k = 
1 . When a message rn is to be signed (or during the precomputation before signing), the token 
generates a random integer b and its inverse b" 1 mod q, where 0<b<q. The token then updates 
a k and k by computing a* <- {a k b~ l mod q)(k) mod q, followed by k <~ b. The signature (r, s) is 
formed from the updated values of a k and k by computing r = ct mod p 9 and s = [(ZT x H(m) mod q) 
+ (ag*) mod q] mod q. As indicated, when computing s y b~ l H(m) mod q and (a*r) mod q are 
computed first, then combined mod q. Note that a* and k should be randomized prior to the first 
operation, since the first update may leak more information than subsequent updates. It is thus 
recommended that a dummy signature (or parameter update) be performed immediately after key 
generation. Valid signatures produced using the leak-resistant DSA algorithm may be checked 
using the normal DSA signature verification procedure. 
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Other Algorithms and Applications 

Other algorithms can be made leak-proof or leak-resistant, or may be incorporated into 
leak-resistant cryptosystems, For example, cryptosystems such as those based on elliptic curves 
5 (including elliptic curve analogs of other cryptosystems), secret sharing schemes, anonymous 
electronic cash protocols, threshold signatures schemes, etc. be made leak resistant using the 
present invention. 

Implementation details of the schemes described may be adjusted without materially 
changing the invention, for example by re-ordering operations, inserting steps, substituting 
10 equivalent or similar operations, etc. Also, while new keys are normally generated when a new 
system is produced, it is often possible to add leak resistance retroactively while maintaining or 
converting existing private keys. 

Leak-resistant designs avoid performing repeated mathematical operations using non- 
changing (static) secret values, since they are likely to leak out. However, in environments where 
15 it is possible to implement a simple function (such as an exclusive OR) that does not leak 

information, it is possible use this function to implement more complex cryptographic operations. 

While the exemplary implementations assume that the leak functions can reveal any 
information present in the system, designers may often safely use the (weaker) assumption that 
information not used in a given operation will not be leaked by that operation. Schemes using this 
20 weaker assumption may contain a large table of precomputed subkey values, from which a unique 
or random subset are selected and/or updated for each operation. For example, DES 
implementations may use indexed permutation lookup tables in which a few table elements are 
exchanged with each operation. 

While leak resistance provides many advantages, the use of leak resistance by itself cannot 
25 guarantee good security. For example, leak-resistant cryptosystems are not inherently secure 
against error attacks, so operations should be verified. (Changes can even be made to the 
cryptosystem and/or leak resistance operations to detect errors.) Similarly, leak resistance by itself 
does not prevent attacks that extract the entire state out of a device (e.g., L^Lmax). For example, 
traditional tamper resistance techniques may be required to prevent attackers from staining ROM 
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or EEPROM memory cells and reading the contents under a microscope. Implemented should 
also be aware of interruption attacks, such as those that involve disconnecting the power or 
resetting a device during an operation, to ensure that secrets will not be compromised or that a 
single leaky operation will not be performed repeatedly. (As a countermeasure, devices can 
increment a counter in nonvolatile memory prior to each operation, and reset or reduce the 
counter value when the operation completes successfully, If the number of interrupted operations 
since the last successful update exceeds a threshold value, the device can disable itself) Other 
tamper resistance mechanisms and techniques, such as the use of fixed-time and fixed-execution 
path algorithms for critical operations, may need to be used in conjunction with leak resistance, 
particularly for systems with a relatively low self-healing rate (e.g., Lmax is small). 

Leak-resistant algorithms, protocols, and devices may be used in virtually any application 
requiring cryptographic security and secure key management, including without limitation; 
smartcards, electronic cash, electronic payments, funds transfer, remote access, timestamping, 
certification, certificate validation, secure e-mail, secure facsimile, telecommunications security 
(voice and data), computer networks, radio and satellite communications, infrared 
communications, access control, door locks, wireless keys, biometric devices, automobile ignition 
locks, copy protection devices, payment systems, systems for controlling the use and payment of 
copyrighted information, and point of sale terminals. 

The forgoing shows that the method and apparatus of the present invention can be 
implemented using numerous variations and modifications to the exemplary embodiments 
described herein, as would be known by one skilled in the art. Thus, it is intended that the scope 
of the present invention be limited only with regard to the claims below. 
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